-
Notifications
You must be signed in to change notification settings - Fork 277
SMT2 back-end: flatten with_exprt operands #8670
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #8670 +/- ##
========================================
Coverage 80.39% 80.39%
========================================
Files 1688 1688
Lines 207383 207402 +19
Branches 73 73
========================================
+ Hits 166731 166748 +17
- Misses 40652 40654 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
016dcc1
to
6edd58a
Compare
We will want to use the solver for more than just selected CBMC regressions.
Solvers without datatypes support require flattening towards bitvectors. This is also true for array-typed expressions when the array is not at the top level (despite possible array-theory support). This changes makes sure we will flatten such array-typed expressions.
This branch does seems to fix the array flattening issue on the mlda-native code when using bitwuzla. TWO functions still fail with a different error though. For example, the unpack-hints function in mldsa-native:
yields
Is this related, or a completely different problem? |
Thank you for testing! I'll take a look tomorrow morning to figure out whether the remaining problem (besides |
Results: testing with CBMC (this branch), Z4 4.12.6 and Bitwuzla 0.7.0 on the mldsa-native, HEAD of main branch - all 134 functions/proofs OK. |
Testing this branch (with 3rd commit) on mlkem-native main/HEAD - all 126 proofs OK. |
Testing this branch (with 3rd commit) on mldsa-native - 134 proofs all OK, and a bit faster too. |
WITH expressions in an ite expression could previously trigger one-sided expression flattening.
Solvers without datatypes support require flattening towards bitvectors. This is also true for array-typed expressions when the array is not at the top level (despite possible array-theory support). This changes makes sure we will flatten such array-typed expressions.